-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gnome: Added 'executable' method for GTK Android #13800
base: master
Are you sure you want to change the base?
Conversation
Oh and I wanted to know if there is maybe a better way of removing executable specific kwargs for the shared library than just setting them to None? I'd also want to be able determine using the target introspection data which target originated from gnome.executable but am unsure how to achieve this. |
dfa3b48
to
0e75aca
Compare
I'm also somewhat unhappy about the type declarations for mypy, it seems somewhat hacky. But I have really no idea how it works |
Previsouly, android_usecase was expected now import('gnome').executable should be used to indicate applications supporting android.
3372f22
to
9ca4b1e
Compare
It would be good to get some thoughts from other GNOME/GTK devs. |
gnome.executable takes in the same arguments as mesons own executable, but it automatically builds a shared library on android and links it with gtk4-android-glue.
btw, who's responsible for vala compiler support in meson? I'd expect that building an gnome.executable[1] that uses vala sources to behave in the end the same as an executable that uses c. This is not the case however with meson producing rather nonsensical ninja files. [1]: I doubt this has anything to do with this changeset that introduces gnome.executable, but rather the build pipeline that gtk-android-builder ends up producing, but its obv. related |
I'm not sure who owns it. I would talk to the Vala people on matrix or discord. I can't remember where they hang out. We could definitely use more Vala contributors. |
As this is an Android specific thing, putting it in the |
I don't really believe it makes a lot of sense for anything outside of building Android applications based on a GTK codebase. I know you can build QT Applications for Android aswell, but I don't know if they target "single shared codebase" like what I target to do. So unless you have a good plan on how to genericize this in a way that benefits building QT applications using meson for Android, I don't really see another place for it |
A new concept for #13767, this time more specifically tailored to GNOME/GTK.
I think having the "gtk4-android-glue" depname hardcoded is fine for now but it makes sense in the future to extend by scanning whether the user is depending on gtk4, 5, ... once there are different possibilities.